let's make it a util or use some small npm module for it (I prefer to have some convenient module) - we can do a follow up

let's rewrite to

let result;
try {
  result = await ...;
}
return result;

the reason is due to huge difference in code execution because of return or return await

same for other places

can you elaborate on the difference in code execution? imo both of them are the same?

if try { return promise } catch ... - it won't catch as promise is not awaited
if try { return await promise } catch ... - will catch and the difference is only in one word

I think it is better to be on a clear side of things and write:

let result;
try {
  result = await ...;
}
return result;

as the absence of await changes so much (and I faced some nasty bugs in the past because of that)

nit: as this pattern repeats 3 times already in the file - let's split it into private method

or because it is repeated in many other places - we can include it into .getStream implementation

include which part?

we will have to handle errors on Filter side as well

I meant this code

try {
      stream = await this.getStream(peer);
    } catch (error) {
      throw new Error(`Failed to get stream for peer ${peer.id.toString()}`);
    }
    ```
it is ok to let `getStream` fail with message and pop up till we want to handle it, we don't need to handle it each on each level, because we are basically doing re-throw 

gotcha. this is now outdated code -- we now return error code instead of throwing